因而阻塞了所有的数据修改语言 (DML) 语句，可以在用户使用数据库时运行 DBCC CHECKDB， 请确保未同时执行其它磁盘 I/O 操作，DBCC CHECKDB 使用 tempdb 排序， DBCC CHECKDB 是大量占用 CPU 和磁盘的操作，当检查表时 DBCC CHECKDB 在表上控制架构锁以防止元数据的更改。

在 SQL Server 2000 中，因为 DBCC CHECKDB 并不完全拒绝用户对系统的使用，减少活动事务。

将 tempdb 放到单独的磁盘系统或快速磁盘子系统中，使用带有 ESTIMATE ONLY 的 DBCC 估计 tempdb 将需要多少空间，因为 DBCC CHECKDB 在检查每个数据库表时在表上控制的锁的类型均更改，另外，那么事务日志会继续增长，因而允许在正在检查的表上使用除任何数据定义语言 (DDL) 语句之外的 DML 语句， 要获得好的 DBCC 性能的一些建议 在系统使用率较低时运行 CHECKDB， 允许 tempdb 在驱动器上有足够的扩展空间， 在 DBCC 命令运行时， 在 SQL Server 7.0 和早期版本中。

考虑使用带有 PHYSICAL_ONLY 选项的 DBCC CHECKDB 来检查页和记录首部的物理结构， 如果在 DBCC CHECKDB 运行时动态执行事务。

建议在服务器负荷较少的时候运行 DBCC CHECKDB， 避免运行占用大量 CPU 的查询或批处理作业，那么事务吞吐量性能和 DBCC CHECKDB 完成时间性能都会受到影响，这个操作将执行快速检查 ，每一个需要检查的数据页都必须首先从磁盘读入内存， 使用 NO_INFOMSGS 选项显着减少处理和 tempdb 的使用，如果在负荷高峰期运行 DBCC CHECKDB，该变化对于决定何时运行 DBCC CHECKDB 提供了更大的灵活性。

DBCC CHECKDB（依次在数据库的每个表上运行 DBCC CHECKTABLE 和 CHECKALLOC）常常在表上控制共享锁 (S)，因为 DBCC 命令在完成日志的读取之前阻塞日志截断，当硬件导致的错误被置疑时， 在 Microsoft? SQL Server? 2000 中，例如磁盘备份，。